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A B S T I  ACT 


This  thesis  is  a  summary  of  the  design  and 
implementation  of  an  operatina  system  interface  and  a  user 
interface  for  an  interactive  qraphics  display  system.  The 
actual  interface  software  and  documentation  are 
characteristic  of  the  Naval  Postgraduate  School 
environment.  Documents  describina  t  h e  actual  software  and 
user  interface  are  d  u  b 1 i  s  h  e  d  separately. 

The  oeneral  problems  and  solution?  involved  in 
implementing  a  real-time  interactive  graphics  process  in  a 
multiprogrammina  environment  are  i  ncl  urled  herein.  The 
problems  and  solutions  discussed  are  related  to  the 
interface  of  a  Vector  General  Graphics  D  i  s  n 1  a  y  Unit  and  a 
Digital  E  a  u  i  p  m  e  n  t  Corporation  POP  -11/50  computer. 
Recommendations  for  possible  future  developments  are  also 
included. 
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I.   INTRODUCTION 


f  h c  problem  a d  c  i  r e s  s  p  d  in  t  hi  s  thesis  is  how  to 
support i  in  a  multiprogramming  environment*  a  process  that 
does  not  conform  to  multiproqram  m  i  n  q  conventions.  Four 
basic  problems  are  identified  in  general  and  related  to  a 
specific  interactive  graphics  environment  in  w h  i  c  h  they 
occur.   The  four  problem  areas  are: 

A.  Operation  System  Modifications 

B.  Interrupt  Interface  Techniques 

C .  User  Interface  techniques 

D .  Accessing  N  o n - C  o  n t  i  o  u  o  u  s  D  i  s  o 1  a  y  Lists 

The  vehicle  used  for  a r ob 1 e m  identification  and  solution 
de  v e  1  op m  e  n  t  w  <i  s  the  vector  General  Interactive  G  r  a  p  hies 
Display  System  [51  and  a  Digital  Equipment  Corporation 
PDP-11/50  computer  [17,181.  The  UNIX  Timesharing  System 
(?01  provided  the  multiprogramming  environment. 

The  Vector  General  Interactive  Graphics  Display  System 
(Vector  General),  as  installed  at  the  '.'aval  Postaraduate 
School,  is  a  highly  sophisticated  display  terminal  with 
hardware  implemented  three  dimensional  rotation, 
translation,  and  scalino  [51.  An  alphanumeric  keyboard 
[ 1 ] ,  lighted  function  switches  with  manual  interrupt  1 4  ]  , 
control  dials  t?l,  ano  light  Pen  [  1  <?  3  are  attached  to  the 
system.  A  circle- a  re  generator  (51  and  a  character 
generator  [ 6 ]  are  included  as  an  integral  part  of  the 
system.   This  graphics  display  system  is  interfaced  with  a 


PDP-11 /SO  computer  having  6 4 K  bytes  of  memory  and  two 
million  bytes  of  d  i  s  <  storage.  This  thesis  discusses  some 
of  the  problems  involved  in  implementing  an  interactive 
or  a  p  hies  interface  and  includes  recommendations  for 
possible  future  developments  in  the  area  of  supporting 
non-cenforrr,  ino  processes  in  a  multiprogramming 
environment.  A  detailed  description  of  the  actual 
interface  design e d  and  inplemented  in  the  course  of  this 
thesis  can  be  found  in  separate  publications  [13rl4], 
These'  publications  include  a  design  manual  »  users  manual  > 
program  listings*  and  documentation.  1  he  interface  is  a 
partial  result  and  extension  of  an  initial  interface 
desiqn  by  Howard  and  Thorpe  1 7  »  B  ]  «. 


IT.   CHARACTERISTICS  OF  MULTIPROGRAMMING  PROCESSES 


Multiprogramming  is  t^e  interleaved  or  concurrent 
execution  of  two  or  more  processes-  [  1 ^ ]  .  Since  the 
physical  memory  reauirements  of  each  process  nay  vary, 
each  orocess  is  designed  to  be  relocated  within  memory. 
This  enables  a  process  to  be  reassioned  within  memory  as 
necessary  to  ensure  efficient  memory  utilization. 
Processes  waiting  for  a  system  resource  are  typically 
swaoped  onto  a  rp^ss  storage  device  thereby  releasing  the 
physical  memory  for  another  process.  In  some  systems  a 
process  may  be  divided  into  segments  or  panes  that  are 
themselves  relocatable  and  swaooable  entities. 


A  multiprogramming  process  typically  is  not  given 
dedicated  use  of  the  central  processor.  Each  process  is 
executed  for  a  time  Quantum  arid  then  set  to  a  wait  state. 
Processes  waiting  to  be  executed  are  placed  in  a  queue 
according  to  some  predefined  priority.  Ihis  is 
characteristic  of  computer  systems  permitting  on-line 
communications  with  multiple  users  fill. 

Since  the  multiorogramming  process  is  relocatable  and 
s  w  ap  a  b 1 e  t  the  user  has  no  knowledge  of  physical  memory 
address  during  p r o g r a rr  execution.  Therefore/  the?  user 
generates  his  p r o  a  r a  m  in  an  imaginary  memory  called 
virtual  memory.  Each  users  virtual  memory  begins  at 
address  zero  and  can,  depending  on  the  operating  system/ 
extend  to  the  maximum  address  of  the  computer.  The 
operating  system  maps  all  virtual  addresses  into  physical 
add i- esses  when  the  process  is  loaded  into  memory.  Some  of 
these  characteristics  conflict  with  characteristics  of  an 
interactive  graphics  croc  ess  as  will  be  shown. 


III.   CHARACTERISTICS  OK  INTERACTIVE  GRAPHICS  PROCESSES 


A.   CRT  REFRESH  REQUIREMENTS 


ivhile  various  types  of  graphics  plotters  have  been 
invented*  the  CRT  disclay  is  the  only  device  suitable  for 
generating  interactive  graphical  output  at  high  speed 
[161.   The  short  persi  stance  of  the  CRT   phosphor   permits 


information  to  be  ouicU v  changed.  This  is  also  the 
princiole  failing  of  the  CRT.  If  a  line  is  displayed  once 
it  ouickl v  fades.  The  problem  can  b  e  remedied  by 
refreshing  the  CRT  but  continual  refreshing  lirrits  the 
number  of  lines  that  can  be  drawn.  If  too  many  lines  are 
displayed  the  intensity  variations  of  the  lines  will  be 
noticable.  This  phenomenon/  called  flicker/  is 
undesirable  a  no  usually  not  permitted.  A  refresh  rate  of 
t  h  i  r  t  y  to  forty  h  e  r  t  ?.  will  prevent.  flicker  but  does 
require  the  ent  i  m  display  to  b  n  displayed  every  thirty- 
three  to  twentv-five  milliseconds.  If  the  computer 
processor  must  be  used  to  directly  refresh  the  CRT 
disolay,  support ino  a  graphics  process  under  a 
multiprogramming  environment  would  be  impractical. 

Recent  developments  in  direct  view  storage  tube 
displays  and  d 1  a s m a  Displays  offer  a  solution  to  the 
refresh  problem  but  in  some  respects  are  l^ss  versatile 
than  the  conventional  C  R  [  .  Another  ponular  approach  to 
the  problem  is  to  build  a  separate  display  processor  whose 
function  is  to  read  the  computer's  memory  arid  use  the  data 
to  generate  the  display.  Refresh  processing  is  then 
handled  by  the  disolay  processor  leaving  the  computer 
processor  free  to  perform  other  tasks. 

The  disolay  processor  techniaue  is  employed  by  the 
Vector  General  using  a  Direct  Memory  Access  channel  (DMA) 
[ 5 1 6 ]  •  Communication  with  the  user  is  maintained  via  a 
frame   clock   interrupt   signal   every   8.33  milliseconds. 
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U  s  i  n  q  the  time  between  interrupts  as  a  timer/  the 
POP- 11/50  computer  can  determine  when  to  initiate  the 
Victor  General  for-  refresh.  This  allows  the  speed  and 
versatility  of  a  conventional  CRT  and  removes  the  refresh 
orocessinci  from  the  PDP-11/50  processor.  The  DMA  is  not  a 
panacea^  however.  It  r e a u i  r e s  the  display  data  to  remain 
in  the  computer  memory  for  the  entire  time  the  data  is 
beino  usen  for  disnlay  generation.  I '.  h  i  1  e  this  is  not  a 
limitation  on  the  computer  processor;  it  is  a  limitation 
on  the  computer  resources.  This  limitation  would  not  be 
noticable  in  a  dedicated  comnuter  environment.  However, 
in  a  multiprogramming  environment  a  1  1  c  o  m  p u  t  e  r  resources 
are  at  a  premium  and  and  any  limitations  imposed  must  be 
consi  dercd. 

B.   MEMORY  MANAGEMENT 

As  previously  mention e a  in  section  11,  the  central 
theme  in  a  n  u  1  t  i  p  r  o  a  r  a  m  m  i  n  cj  environment  is  that  all  active 
processed  may  be  relocatable  within  memory.  Processes  may 
also  be  remove d,  or  swappea  onto  a  mass  storape  device. 
This  permits  efficient  use  of  computer  processor  time  end 
computer  memory.  But,  this  also  conflicts  with  the  D M A 
capability  of  the  display  processor. 

Before  the  DMA  can  be  used/  some  method  of  ensurino 
the  entire  display  list  is  resident  in  memory  must  be 
founo.  In  addition,  the  display  list  must  not  to  be 
relocated  or  swapped.   These  restrictions,  while  necessary 


1  1 


to  ensure  the  disnl  .iv  processor  c  f\n  address  the  display 
1  i  s  t  r  must  also  be  time  minimized.  Only  while  the  display 
processor  is  actually  using  the  display  list  for  display 
generation  rrust  those  restrictions  apply.  Therefore/  some 
ret  hod  of  de  t  e  nr  i  n  i  iv.:  which  disci  ay  list  is  active  must  be 
found. 


IV.   GRAPHICS  INTERFACE  DESIGN! 

A.   OPERATING  SYSTEM  MODIFICATIONS 

Implementation  of  the  graphics  interface  r  ea  u  i  r  e  d  t  h a  t 
the  memory  allocation  scheme  of  UMIX  be  modified  to  perrrit 
the  Vector  General  Graphics  Display  System  to  access  the 
Graphics  display  list.  The  modification  adopted  involved 
creation  of  a  unique  real-time  process.  Whenever  a  user 
declares  his  intention  to  use  the  Vector  General*  the 
user's  entire  process  is  placed  in  physical  memory  and 
flapped  as  non-swaoable  and  non-relocatable.  Followino 
the  real-time  process  recommendations  of  Krai  ( 1 0 ] f  the 
process  priority  is  also  increased  to  ensure  the  real-time 
process  is  at  the  head  of  the  process  nueue.  The  process 
priority  chance  has  been  found  to  be  necessary  only  if  the 
computer  processor  is  perforrnina  the  disolay  refresh.  It 
is  not  needed  with  D  )'vl  A  and  its  action  prevents  the 
computer  processor  from  servicing  any  other  process.  The 
modifications  implemented?  while  comparatively  simpler  oo 
not  consider  memory  as  a  limited  resource  nor  is  the   time 
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minimization  factor  considered. 

An  alternate  solution  to  the  one  i mo 1  em en ted  requires 
additional  modifications  to  the  operating  system  but  does 
treat  rremorv  as  a  limited  resource.  This  involves 
splitting  a  user  process  so  that  the  instruction  space  and 
the  data  so ace  are  treated  separately.  When  a  user 
declares  his  intention  to  use  the  graphics  terminal,  the 
operating  s  y  s  t e  m  c 1  a  c  e  s  the  restrictions  only  o  n  the  data 
so ace.  The  instruction  so  ace  remains  unchanged.  This* 
however ,  still  aces  not  consider  the  time  minimization 
factor.  T  h e  user  could  declare  his  intentions  to  use  the 
graphics   terminal   a  n  d   then   never   do   so.    Y  e t ,  the 

resources  would  bp  allocated. 

If  a  o  r  o  c  e  s  s  were  permitted  to  complete  all 
calculations  and  data  manipulations  involving  display  list 
preparation  prior  to  becoming  a  real "time  process*  the 
period  of  time  in  which  memory  is  allocated  to  thr>  real- 
time process  would  be  reduced  to  the  actual  display  time. 
The  operation  system  would  then,  at  display  time>  locate 
the  display  list  reference o  by  the  display  request  end 
make  that  list  a  real-time  entity. 

A  t  h.  i  r  o  solution  alternative  is  directly  related  to 
the  capabilities  of  the  Vector  General  Graphics  Display 
System  and  the  UNIX  operating  system.  The  address 
structure  of  the  Vector  General's  DMA  channel  is  such  that 
the  display  processor  can  dynamically  access  only  3 2 K 
bytes   of   memory.    A   display   processor  command  defines 
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which  32K  bvte  memory  block  is  to  op  addressed. 

The  UNIX  operating  system  treats  the  instruction  and 
d  a  t  a  space  of  a  process  as  a  s  i  n o 1 e  entity  with  the  o  a  t  a 
space  aooended  immediately  following  the  instruction 
space.  If  the  virtual  addressing  scheme  of  UNIX  were 
modified  so  that  the  first  address  of  the  data  space  was 
virtual  address  zero*  the  r  e  a  1  - 1  i  m,e  process  modifications 
would  be  simplified.  At  display  t  i  m e /  the  process  could 
be  allocated  across  a  3  ?  K  byte  memory  address  boundary 
with  its  data  space  beginning  at  the  boundary  address. 
Virtual  addresses  would  then  be  a  physical  eaoross  offset 
from.  the  address  boundary.  ft  h  i  1  e  not  providing 
treTendous  asset  for  memory  management*  this  solution 
would  greatly  enhance  the  display  manipluation 
capabilities. 

A  less  appealing  but  easier  implementation  of  the 
virtual  addressing  modification  woulo  be  to  ensure  the 
entire  virtual  address  space?  instruction  and  data?  begins 
on  a  3?K  byte  memory  block  boundary.  The  data  soacc » 
while  still  an  adoress  offset*  would  not  be  virtual 
address  zero.  This  implementation  would  reduce  the  total 
available  data  space  by  the  size  of  the  instruction  s  p  a  c  ^ 
but  the  additional  memory  space  used  is  that  of  the  real- 
time process.  Therefore*  any  addressing  errors  within  the 
Vector  General  would  only  affect  the  instruction  and  data 
space  of  the  real-time  process. 
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B,   INTERRUPT  INTERFACE  TECHNIQUES 

A  nunber  of  araphics  devices  have  been  invented  for 
the  input  of  graphical  information  to  a  computer.  When 
used  with  d  oraohics  disrlay  the  devices  make  it  possible 
to  effectively  interact  with  the  program.  Generally/  the 
simplest  way  to  handle  inputs  from  these  devices  is  by 
means  of  interrupt  routines  which  receive  the  input  (lata 
and  pass  it  on  to  user  the  prograrr  in  the  form  of  an 
interrupt  signal  116] .  Since  the  user  exists  in  the 
relocatable  process  space  of  a  virtual  machine/  the 
oneratina  svstem  must  provide  the  link  between  the 
interruot  service  routine  and  the  user  interrupt  signal 
routine.  This  operation  requires  some  effort  and  may  take 
as  much  as  one  hundred  milliseconds  if  the  process  has  to 
tie  ret  reived  from  the  d  i  s  k  .  Considering  the  frequency  of 
frame  clock  interrupts  (8.33  milliseconds)  plus  the 
occurance  of  any  device  interrupts/  it  is  likelv  that- 
multiple  interrupts  will  occur  while  waiting  for  the 
operating  system  to  process  the  first  interrupt. 

The  UNIX  operating  system  has  no  capability  of 
hand  lino  multiple  interrupts  nor  of  determining  the 
priority  of  interrupts  received  from  the  same  peripheral 
device.  Because  of  the  nature  of  some  graphics  devices/ 
only  one  interrupt  may  occur.  Therefore/  it  is  important 
to  ensure  the  preservation  of  each  interrupt.  The  Vector 
General   interface  employs  a  technique  that  eliminates  the 
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need  to  pass  all  but  device  interrupts  to  the  user.  The 
user  is  required  to  provide  the  interrupt  service  routine 
with  the  desired  refresh  rate.  This  determines  the  number 
of  frame  clock  interrupts  permitted  before 
reinitialization  of  the  d  i  s  p 1  a  y  list.  The  interrupt 
service  routine  then  handles  the  refresh  ti^ino  without 
requiring  any  action  from  the  user  program. 

When  a  device  interrupt  occurs i  the  values  of  specific 
Vector  General  registers  i^-re  extracted  prior  to  as  kino  the 
ooerating  system  to  s  i  a  n  a  1  the  user  program.  These  values 
representing  the  interrupt  state  of  the  Vector  General  ^re 
r  e  t  a  i  n  e  d  by  the  0  e  v  i  c  e.  interrupt  service  routine  until  the 
user  program  explicitely  asks  for  the  values.  Included  in 
these  interrupt  values  is  a  Vector  General  status  word 
indicating  which  interrupts  have  occur  e  d  I  c"> )  .  This 
feature  enables  the  user  to  define  which  device  has 
priority  and  any  desire d  action  to  he  taken. 

C.   INTERFACE  TECHNIQUES 

The  user  interface  software  has  been  designed  to  make 
the  detailed  operation  of  the  Vector  General  transparent 
to  the  user.  The  basic  concept  is  to  define  high  level 
constructs  which  the  user  interface  routines  convert  into 
Vector  General  commands.  There  are  three  classes  of 
constructs  defined:  objects^  elements/  and  the  picture. 
An  object  is  the  lowest  level  construct  which  can  be 
displayed   alone.   Each  object  is  independently  rotatable* 
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scalable/  and  translatable  into  any  Portion  of  a  thirty 
inch  bv  thirty  inch  Dicture  soace.  An  object  can  be  as 
large  as  fifteen  inches  by  fifteen  inches  ana  be  rotated 
or  positioned  to  the  extreme  limits  of  the  picture  space 
without  distortion  to  any  of  the  remaining  visible 
portion.  Each  object  is  composed  of  one  or  more 
independently  light  pen  h  o  o  k  a  b  1  e  elements.  An  element  is 
composed  of  a  series  of  user  drawn  images  or  characters 
entirely  relative  to  the  untransformed  image  space  of  its 
object.  An  object  c  a  n  be  defined  unrotated  in  such  a  way 
as  to  fill  the  entire  object  soace  and  then  be  scaled/ 
rotated/  and  n>oved  so  that  the  i^age  space  is  the 
appropriate  si  ?e(  is  viewed  from  the  a  p  p  r  e  p r i  a  t  e  aspect/ 
and  is  in  the  appropriate  area  of  the  picture.  The 
picture  defines  the  picture  scale  a no  screen  coordinates 
for  all  objects. 

The  user  is  responsible  for  the  oeneration  and  content 
of  each  element.  Prior  to  its  inclusion  within  the 
display  list,  the  user  must  fill  each  element  with  the 
necessary  draw  and  move  commands.  In  addition/  the  user 
must  provide  three  unused  words  succeedino  the  draw-move 
commands.  These  three  words  are  used  by  the  interface 
routines  to  ensure  each  element  is  properly  terminated. 
This  prevents  the  Vector  General  from  accessing  memory 
outside  the  a i splay  list  if  the  user  fails  to  properly 
terminate  the  display  list. 

The  generation  and  content   of   all   objects   and   the 
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picture  is  t ho  responsibility  of  the  interface  software. 
A  set  of  routines  are  provided  to  link  el  orients  to  objects 
and  objects  to  the  picture.  Dynamic  modification  of 
objects  and  picture  parameters  is  also  provided.  However, 
it  is  the  user's  responsibility  to  dynamically  modify  the 
e 1 ement  content . 

0.   ACCESSING  NON-CONTIGUOUS  DISPLAY  LISTS 

One  of  the  basic  requirements  of  an  interactive 
graphics  system  is  that  the  picture  can  be  changed 
dynamically.  Iris  ea^  be  dono  hy  regenerating  the  entire 
display  list  or  segmenting  the  display  list  and 
r  e  g  e  n  e  r  a  t  i  n  a  t  h »  modified  segment.  Segmenting  the  display 
list  also  permits  sharing  of  display  code  in  a  manner 
somewhat  analogous  to  conventional  subroutines.  This  does 
require  some  means  of  generating  the  display  from  non- 
contiguous display  1  i  s  t  <~-  -  A  list  of  the  non-continuous 
display  lists  could  be  created  and  sent  to  the  display 
processor  or  the  non-contiguous  display  lists  could  be 
linked  within  the  display  list  itself.  The  Vector  General 
is  capable  of  Poth  types  of  operation.  The  latter  method 
was  used  for  the  interface  implementation.  This  method 
requires  less  communication  with  the  POP- 11/50  computer. 

The  concept  of  display  subroutine  calls  implies  the 
ability  to  store  the  present  state  before  performing  the 
subroutine  jump.  This  usually  is  implemented  by  a  Last- 
In-First-Out   stack   [91.     The    PivA    is    normally    a 
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bidirectional  channel ,  therefore  the  display  processor  has 
access  to  the  computer's  memory  for  manipulation  of  a 
stack.  With  appropriate  instructions  and  addresses 
encoded  in  the  d  i  s  n  1  a  y  list.,  the  display  processor  can  now 
access  non-contiguous  display  lists.  Reference  1  Q 
contains  a  description  of  the  Vector  General  subroutine 
stack. 

Permittina  trio  display  processor  to  write  into  memory 
creates  a  data  protection  problem  in  a  shared  memory 
environment.  The  display  processor  cannot  be  allowed  to 
write  indiscriminately  throughout  memory.  The  integrity 
of  the  operating  system  a no  other  user  processes  must  be 
maintained.  A  stack  area  provided  by  the  user  would 
enable  the  display  processor  to  determine  where  to  a oar ess 
memory  for  all  write  operations.  However^  the  D  ■'- 
bypasses  the  operating  system's  underflow  and  overflow 
protection  mechanism.  Therefore/  an  a  a  dressing  error 
could  cause  modification  of  the  operating  system  or 
another  user  process.  Some  method  must  be  used  to  limit 
the  access  range  of  the  display  processor.  bounds 
registers  in  the  display  processor  is  a  reasonable 
solution.  These  registers,  set  by  the  computer  processor, 
would  limit  the  area  of  addressability  by  the  display 
processor.  If  the  bounds  registers  applied  to  read  as 
well  as  write  operations,  unbounded  display  lists  could 
also  be  easily  detected.  Ihe  Vector  General's  3  <?  K  byte 
memory   addressinq   limitation   is   analooous   to  a  set  of 
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fixed  boundary  rcsisters.  Since  the  typical  display  list 
dops  riot  require  the  full  3?K  bytps  of  memory,  the  display 
rrnc?ssor  does  have  the  potential  of  addressing  outside 
the  real-time  process.  The  Vector  General  interface 
routines  rninimi/e  the  problem  in  three  ways.  First,  the 
user  himself  does  not  define  the  subroutine  stack  nor  does 
he  use  the  subroutine  stack  directly.  This  is  handled  by 
the  interface  routines*  Second?  the  stack  has  a  software 
underflow  mechanism  provided  by  trie  interface  routines. 
An  underflow  trans  to  a  Vector  General  halt  instruction. 
Third ,  each  display  list  is  terminated  in  such  a  manner 
that  the  d  i  s  n  1  a  v  list  cannot  be  accessed  beyond  its 
defined  length. 

Realistically^  there  is  no  way  to  share  the  same  3 ? K 
byte  memory  block  with  a  Vector  General  process  and  ensure 
one  hundred  oercent  integrity.  A  user  could  include 
commands  in  his  disnlay  list  that  cause  an  undetected 
stack  overflow  or  a  jump  to  an  area  outside  of  the  process 
limits.  The  Vector  General  instructions  defining  these 
actions  ?>re  not  rnake  available  to  the  user  but  a  display 
error  could  result  in  such  an  instruction. 
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VI .   RECOMMENDAT IONS 
A.   UNIX  KODIFICATIO! 

1.  Process  Priority 

The  current  implementation  of  the  interactive 
graphics  interface  requires  each  process  requesting  use  of 
the  Vector  General  to  change  its  priority  as  part  of  the 
real-time  system  call.  This  is  a  necessary  requirement 
only  for  those  r e  a  1  - 1  i  m  e  processes  performing  the  refresh. 
The  increased  priority  ensures  the  real-time  process  is 
placed  at  the  top  of  the  process  run  queue.  The  direct 
memory  access  capability  of  the  Vector  General  d o e s  not 
require  the  process  to  refresh  the  display  directly. 
Therefore/  the  increased  priority  of  the  real-time  process 
is  not  needed  for  the  Vector  General.  If  the  UNIX 
operating  system  were  modified  to  allow  a  process  to  be 
real-time  without  changing  its  priority/  the  affect  of  a 
real -time  process  on  the  multi-user  environment  would  be 
reduced. 

2 .  Memory  Allocation 

The  memory  allocation  scheme  of  UNIX  presently 
requires  both  the  instruction  space  and  the  data  space  to 
be  loaded  contiquously  in  memory.  The  only  requirement 
for  the  Vector  General  real-time  process  is  that  the 
active  display  list  (data)  be  locked  within  a  3  2  K  byte 
memory  block.  If  a  process  could  be  split  so  only  its 
data  space  was   real-timer   the   system   memory   resources 
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currently  allocated  *or  the  rral-t  ime  process  instruction 
space  would  be  available  for  other  uses.  T  h  n  size  of  the 
Vector  General  d a t  a  space  couln  also  bo  increased*  thereby 
permitting  -norc  complex  display  lists. 

B.   USER  INTERFACE  MODIFICATIONS 

1  .   Picture  Notation 

As  mentioned  earlier*  the  only  display  construct 
capable  of  being  rotated  is  an  object.  At  times  the  u^er 
may  desire  to  rotate  the  entire  picture.  This  cap  a b  i 1 i  t  y 
should  be  provided.  Implementation  of  this  feature  must 
ensure  the  capability  of  rotating  objects  is  not  imoared. 

2 .  D  i s p lay  Enable 

A  limitation  discovered  by  personnel  us  inn  the 
interface  is  the  inability  to  t  e m p  o  r  a  r  i 1 y  prevent  the 
display  of  an  element  or  an  object  without  actually 
d  e 1 e  t  i  n  o  it  from  the  display  list.  The  Vector  General  has 
this  capability  but  it  is  not  extended  to  the  user. 

3 .  Increment  Timing 

The  proposed  cesion  interface  of  Howard  and  T  h  o  r p  e 
17,8)  included  a  m  o  t  i  e  n  feature  that  allowed  t  h  e  user  to 
automatically  have  an  object  nnovp  across  the  screen.  The 
user  defined  motion  vector,  usina  the  frame  clock 
interrupts  as  a  timer,  automatically  incremented  the 
Dosition  of  specified  objects  by  the  values  of  thp  motion 
vector.  The  actual  implementation  could  not  include  this 
feature  because   of   the   relationship   between   th^   user 


22 


process  and  the  frame  clock  inter' runts.  The  orlv  timer 
I '  rv  I  X  has  provided  is  in  increments  of  one  second  and  that 
timer  is  stooped  by  any  interrupt  signal.  Ihercforr,  it 
is  entirely  u  n  s  u  i  t  e  d  for  a  display  motion  timer. 
Implementation  of  this  capability  would  enhance  the  use  of 
the  Vector  General  and  s  i  tn  d  1  i  f  y  the  user  program. 
4 .   Display  List  Generation 

The  importance  of  p r o  q r  a  m m  i  n  q  1  a  n  a  u  a  g  e  s  is  often 
fo root  ten  when  a  qraohics  system  is  designed.  The 
d  e  s  i  o  n  e  r  becomes  involved  in  the  issups  of  display  file 
structures  and  graphical  interaction  leaving  the  provision 
of  a  convenient  prooramming  language  until  later.  This 
lack  of  interest  in  the  development  of  programming 
1  a n a u a q e s  has  been  one  of  the  major  obstacles  preventing 
the  widespread  use  of  graphics  (lol.  Until  such  a 
language  is  developed/  the  unfortunate  programmer  is 
forced  to  write  in  machine  or  assembly  language.  This 
interface  design  has  considered  only  part:  of  the  problem. 
Several  interface  routines  have  been  provided  to  simplify 
the  actual  access  to  the  Vector  General.  The  creation  of 
the  display  list  used  to  generate  pictures  must  still  be 
accomplished  in  the  octal  machine  languaoe  described  by 
Thorpe  N  4  ,  1  5  ]  .  Before  the  existing  interface  will  be  of 
use  to  the  qeneral  oraohics  programmer*  a  simple  methoo  of 
generating  display  lists  must  be  found.  On  this  si  nolo 
capability  may  hinop  the  success  of  the  existing  interface 
structure. 
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VII.   CONCLUSION 

The  Vector  General  interface  desicned  and  implemented 
b y  Thorpe  II 4 , 1 5 J  is  operational  with  no  known  buqs  in  any 
of  the  interface  routines.  The  hardware  suncort  and 
direct  memory  access  capabilities  of  the  Vector  General 
Interactive  Graphics  Display  System  have  been  the  key  to  a 
successful  interface.  Without  the  hardware  support  it  is 
questionable  whether  any  multi-'user  capabilities  would  be 
available  while  using  the  Vector  General. 
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